This chapter discusses data compression on a 2210 over Frame Relay and PPP interfaces. It includes these sections:
Data compression is supported on Frame Relay and PPP interfaces.
The data compression system provides a means to increase the effective bandwidth of networking interfaces on the device. It is primarily intended for use on slower speed WAN links.
Data compression on the device is supported on PPP and Frame Relay interfaces:
The device provides two compression protocols: the Stac-LZS protocol, defined in RFC 1974; and the Microsoft Point-to-Point Compression protocol (MPPC), described in RFC 2118. Both of these are based on compression algorithms provided by Stac Electronics.
Data compression on the device provides a means to increase throughput on network links by making more efficient use of the available bandwidth on a link. The basic principle behind this is simple: represent the data flowing across a link in as compact a manner as possible so that the time needed to transmit it is as low as possible, given a set speed on a link.
Data compression may be performed at many layers in the networking model. At one end of the spectrum, applications may compress data prior to transmitting it to peer applications elsewhere in the network, while at the other end of the spectrum devices may be performing compression at the data link layer, working purely on the bit stream passing between two nodes. How this compression is done and how effective it is depends on a variety of factors, including such things as what network layer the compression is performed at, how much intrinsic knowledge the compressor and decompressor have about the data being compressed, the compression algorithm chosen, and the actual data being compressed. The best compression can usually be performed at the application layer; for example, a file transfer application usually has the luxury of having an entire file of data available to it prior to attempting compression, and it may be able to try different compression algorithms on the file to see which performs best on that particular file's data. Although this may provide excellent compression for that one type of application, it does little to solve the general problem of compressing the bulk of the traffic flowing over a network, as most networking applications do not currently compress data as they generate it.
Compression on the device takes place at a much lower networking layer, at the data link layer. In the device, compression is performed on the individual packets which are transmitted across a link. The compression is done in real-time as packets flow through the device: the sender compresses a packet just prior to transmitting it, and the decompressor decompresses the packet as soon as it receives it. This operation is transparent to the higher layer networking protocols.
Data compressors work by recognizing "redundant" information in data, and producing a different set of data which contains as little redundancy as possible. "Redundant" information is any information which can be derived and recreated based on the currently available data. For example, a compressor might function by recognizing repeated character patterns in a data stream and replacing these repeated patterns with a shorter code sequence to represent that pattern. As long as the compressor and decompressor agree on what these code sequences are then the decompressor can always recreate the original data from the compressed data.
This mapping of sequences in the original data to corresponding sequences in the compressed output is commonly called a data dictionary. These dictionaries may be statically defined - experienced-based information available to the compressor and decompressor - or they may be dynamically generated, usually based on the information being compressed. Static dictionaries are most applicable to environments where the data being processed is of a limited, known nature, and not very effective for general-purpose compressors. Most compression systems use dynamic dictionaries, including any compressors used on the device. On a 2210 the data dictionaries are based on the current packet being processed and possibly previously seen packets, but there is no ability to "look ahead" in the data stream as may exist when compression is performed at other layers. For systems where the data dictionary is dynamically derived and based only on previously seen data, the dictionary is also commonly known as a history. The terms history and data dictionary will be used interchangeably throughout the remainder of this chapter, though it should be understood that in other environments a history is a specific form of data dictionary.
The fact that the device uses dynamic dictionaries and that the compressor and decompressor must keep their dictionaries in synchronization means that data compression works on a stream of data passing between two endpoints. Hence, compression on the router is a connection-oriented process, where the endpoints of the connection are the compressor and decompressor themselves. When compression is started on the stream, both ends reset their data dictionaries to some known starting state, and then they update that state as data is received.
Compression could be performed on each individual packet, resetting the histories prior to processing each packet. Normally though, the data dictionaries are not reset between packets, which means that the histories are based not only on the contents of the current packet, but also the contents of previously seen packets. This usually improves the overall compression effectiveness, because it increases the amount of data which the compressor searches looking for redundancy to remove. As an example, consider the case of one host "pinging" another host with IP: a series of packets is sent out, each one usually nearly identical to the last one sent. The compressor may have little luck compressing the first packet, but it may recognize that each subsequent packet looks very much like the last one sent, and produce highly compressed versions of those packets.
Because the compressor and decompressor histories change with each packet received, the compression mechanisms are sensitive to lost, corrupted, or reordered packets. The compression protocols employed by the device include signalling mechanisms whereby the compressor and decompressor can detect loss of synchronization and resynchronize to each other, such as might be necessary when a packet is lost due to a transmission error. Typically this is done by including a sequence number in each packet which the decompressor will check to make sure it is receiving all packets, in order. If it detects an error, it will reset itself to some known starting state, signal the compressor to do likewise, and then wait (discarding incoming compressed packets) until the compressor acknowledges that it has also reset itself.
Compression on a link typically is performed on data going in both directions over the link. Normally, each end of a connection has both a compressor and decompressor running on it, communicating with their analogs at the other end of the connection, as shown in Figure 10. The output (compression) side runs independently of the input (decompression) side. It is possible for completely different compression algorithms to be operating for each direction of the link. When a link connection is established, the compression control protocol for the link will negotiate with the peer to determine the compression algorithms used for the connection. If the two ends cannot agree on compression protocols to use, then no compression will be performed and the link will operate normally - packets will simply be sent in uncompressed form.
Figure 10. Example of Bidirectional Data Compression with Data Dictionaries
*--------------------------------------*
| NODE A |
| To Higher Layers |
| * ^ |
| | | |
| | | |
| V * |
| *---------------* *--------------* |
| | *-- - - - -* | | *- - - - - * | |
| | |Dictionary| | | |Dictionary| | |
| | *-- - - - -* | | *- - - - - * | |
| | | | | |
| | Compressor | | Decompressor | |
| *--------------** *^-------------* |
*----------------+-----+---------------*
* *
Data Link Connection
(single stream)
| *
*----------------+-----+---------------*
| NODE B | | |
| *--------------V* **-------------* |
| | *-- - - - -* | | *- - - - - * | |
| | |Dictionary| | | |Dictionary| | |
| | *-- - - - -* | | *- - - - - * | |
| | | | | |
| | Decompressor | | Compressor | |
| *---------------* *--------------* |
| * ^ |
| | | |
| V * |
| To higher layers |
*--------------------------------------*
|
A stream really represents a connection between a specific compression process on one end of a link and an associated decompression process on the other end of a link, and thus is more specific than just a "connection" between two nodes; it is possible that a sophisticated compression protocol could split the data flowing between two hosts into multiple streams, compressing each of these streams independently. For example, PPP's CCP has the ability to negotiate the use of multiple histories over a single PPP link, though the router does not support this.
The choice of whether or not to use data compression is not always an easy one. There are several factors which should be considered before enabling compression on a connection.
Data compression is a computationally expensive procedure. As the amount of data being compressed increases (per unit time), the more of a load is put on the device's processor. If the load becomes too great, the performance of the device degrades - on all network interfaces, not just the ones where compression is being performed.
The device actually contains multiple processors and uses asymmetric multiprocessing - for example, link I/O controllers which operate in tandem with the main processor - so the effect of the processor loading is not always readily measured. Because the compression operation may be overlapped with the transmission of packets, this loading may in fact be totally transparent and pose no problem. Nonetheless, it is possible to overburden the device's processor and degrade performance.
As a general rule of thumb, compression should only be enabled on slow speed WAN links - probably only for links with speeds up to about 64 kilobits per second (the speed of a typical ISDN dial link). The total bandwidth for data being compressed on all links probably should be limited to several hundred kilobits per second. Running compression on all channels of an ISDN Primary Rate adapter would be unwise.
The Encoding Subsystem parameters allow you to limit the number of connections which may be concurrently running compression. More interfaces can be enabled for compression then than are actually running it. Once the limit on the number of active compression connections is reached, additional connections will simply not negotiate the use of compression, at least not until an existing compression link shuts down.
Another issue to consider when configuring compression is the memory requirement. Compression and decompression histories occupy a fair amount of memory, which is a limited resource in the device. The Stac-LZS algorithm for example requires about 16 KB for a compression history, and about 8 KB for a decompression history. This problem is magnified by the fact that these histories must exist for each connection which is established: a compression history is synchronized with a corresponding decompression history in a peer router. For a PPP link, this implies one compression history and one decompression history (assuming that data compression is running bidirectionally on the link). On a Frame Relay link, there could be many such histories required, one pair for each virtual connection (DLCI) which is established.
The device creates a pool of compression and decompression histories when it boots. These are always allocated in pairs known as compression sessions - a session is simply one compression history coupled with one decompression history. Technically, compression and decompression are independent functions, but in practice compression is almost always run bidirectionally and so memory is managed and configured in terms of sessions rather than individual histories as a way of simplifying operation. Since different compression algorithms have different memory requirements for compression and decompression, the session is sized to approximately 30 KB to handle the worst case. The pool of compression sessions is populated as configured in the Encoding Subsystem feature. See Configuring and Monitoring the Encoding Subsystem for details.
Whenever the device attempts to establish a compression connection on a link, it begins by reserving a session from the allocated pool of sessions. If no sessions are available, then compression is not performed on that connection. The router may attempt to start compression on that connection later as sessions become available.
The number of compression sessions which are allocated is a configurable parameter. Setting the number of sessions allocated limits both the amount of memory used and the maximum number of connections which may be simultaneously operating with compression. Limiting the number of simultaneously operating compression connections provides a means to help control the CPU loading problem.
The actual nature of the data being transmitted on a connection should be considered before enabling compression for that connection. Compression works better on some types of data than others. Packets which contain a lot of nearly identical information - for example a set of packets generated from an IP "ping" - will normally compress extremely well. A typical assortment of random text and binary data going over a link will usually compress in ratios around 1.5:1 to 3:1. Some data simply will not compress well at all. In particular, data which has already been compressed will seldom compress further. In fact, data which has been previously compressed may actually expand when fed through the compression engine.
If it is known in advance that most of the data flowing over a connection will consist of compressed data, then it is recommended that compression not be enabled for that connection. An example where this might occur is a connection to a host which was set up to be primarily a FTP file archive site, where all the files available to be transferred are stored in compressed form on the host.
A final factor to consider is the nature of the network link between the two hosts. Compression could be performed at a lower layer than even the device's hardware interfaces. In particular, many modern modems incorporate data compression mechanisms in their hardware and firmware. If compression is being performed on the link at a lower layer (outside the device), then it is best not to enable data compression on the device for that interface. As already mentioned, compressing an already compressed data stream is normally ineffective, and in fact may degrade performance slightly. Unless there is some particular reason to believe that the router will do a much better job of compression than the link hardware, it is best to let the link hardware do the compression.
The 2210 uses the PPP Compression Control Protocol (CCP) to negotiate the use of compression on a link. CCP provides a generalized mechanism to negotiate the use of a particular compression protocol, possibly even using a different protocol in each direction of the link, and various protocol-specific options. The software supports the Stac-LZS and MPPC protocols, so the peer must also provide support for at least one of these algorithms to successfully negotiate data compression between the two nodes. The two nodes must also agree on the algorithm-specific options for compression to operate.
To configure data compression on PPP links:
You can display the current compression configuration using the list ccp command.
Table 18 lists the available commands and Figure 11 is an example of configuring compression on a
PPP link. For detailed descriptions of these commands, see 'Point-to-Point Configuration
Commands' in Software User's Guide.
Table 18. PPP Data Compression Configuration Commands
| Data Compression Command | Action |
|---|---|
| disable ccp | Disables data compression. |
| enable ccp | Enables data compression. |
| set ccp options | Sets options for the compression algorithm. |
| set ccp algorithms | Specifies a prioritized list of compression algorithms. |
| list ccp | Displays compression configuration. |
Figure 11. Example of Configuring Compression on a PPP Link
Config>net 6 (1) PPP 6 Config>enable ccp PPP 6 Config>set ccp alg (2) Enter a prioritized list of compression algorithms (first is preferred), all on one single line. Choices (can be abbreviated) are: STAC-LZS MPPC Compressor list [STAC-LZS]? stac mppc PPP 6 Config>set ccp options STAC: check mode (0=none, 1=LCB, 2=CRC, 3=Seq, 4=Ext) [3]? STAC: # histories [1]? PPP 6 Config>li ccp CCP Options ----------- Data Compression enabled Algorithm list: STAC-LZS MPPC STAC histories: 1 STAC check_mode: SEQ MPPE Options ------------ MPPE disabled Optional encryption Key generation: STATEFUL |
Notes:
If you set multiple algorithms, the order of the algorithms determines the negotiation preference for the link.
Certain dial-in client implementations may not be able to connect if the router supports multiple compression protocols on one link. If you encounter this, set the ccp protocol to either STAC or MPPC.
If you enter set ccp algorithms none, the software will automatically disable compression on the link.
If MPPE is enabled and CCP is enabled, MPPC is the compression algorithm.
You monitor compression as you would other PPP components. 'Accessing the Interface Monitoring
Process' in Software User's Guide describes how to access the PPP console environment and details
about the commands. Table 19 lists the compression-related commands. Figure 12 shows an example of listing compression on a
PPP interface.
Table 19. PPP Data Compression Monitoring Commands
| Command | Function |
|---|---|
| list control ccp | Lists CCP state and negotiated options. |
| list ccp | Lists CCP packet statistics. |
| list cdp or list compression | Lists compressed datagram statistics. |
Figure 12. Monitoring Compression on a PPP Interface
+ network 1 PPP > list control ccp CCP State: Open Previous State: Ack Sent Time Since Change: 2 minutes and 52 seconds Compressor: STAC-LZS histories 1, check_mode SEQ Decompressor: STAC-LZS histories 1, check_mode SEQ MPPE: Not negotiated PPP > list ccp CCP Statistic In Out ------------- -- --- Packets: 2 3 Octets: 18 27 Reset Reqs: 0 0 Reset Acks: 0 0 Prot Rejects: 1 - PPP > list cdp Compression Statistic In Out --------------------- -- --- Packets: 19541 19542 Octets: 2550673 2740593 Compressed Octets: 821671 899446 Incompressible Packets: 0 0 Discarded Packets: 0 - Prot Rejects: 0 - Compression Ratios: 3.11 3.24 |
After configuring the global compression parameters and enabling compression on the interface, you must then set the parameters for each individual circuit (PVC) on the Frame Relay interface. Each circuit defined for the interface may have compression enabled on the circuit, and each circuit which successfully negotiates the use of compression uses one compression session from the global pool. You can also disable compression on the interface which means none of the circuits on that interface will be eligible to carry compressed data traffic.
To configure data compression on FR links:
You can display the current compression configuration using the list lmi or list permanent-virtual-circuit commands.
Table 20 lists the commands available for configuring compression on a Frame Relay link and Figure 13 is an example of configuring a Frame Relay Link. See "Frame Relay Configuration Commands" in Software User's Guide for details.
Figure 13. Example of Configuring Compression on a Frame Relay Link
Config> net 2
Frame Relay user configuration
FR Config> enable compression
Maximum number of run-time compression circuits (zero means no limit) [0]? 0
Do you want orphan PVCs to perform compression [Y]? n
The number of currently defined non-compression PVCs is 4
Would you like to change them all to compression PVCs [N]? y
FR Config> add perm
Circuit number [16]? 22
Committed Information Rate (CIR) in bps [65536]?
Committed Burst Size (Bc) in bits [64000]?
Excess Burst Size (Be) in bits [0]?
Assign circuit name []? cir22
Is circuit required for interface operation [N]?
Do you want to have data compression performed [Y]?
FR Config>list lmi
Frame Relay Configuration
LMI enabled = No LMI DLCI = 0
LMI type = ANSI LMI Orphans OK = Yes
CLLM enabled = No Timer Ty seconds = 11
Protocol broadcast = Yes Congestion monitoring = Yes
Emulate multicast = Yes CIR monitoring = No
Notify FECN source = No Throttle transmit on FECN = No
Data compression = Yes Orphan compression = No
Compression PVC limit = None Number of compression PVCs = 2
PVCs P1 allowed = 64 Interface down if no PVCs = No
Timer T1 seconds = 10 Counter N1 increments = 6
LMI N2 error threshold = 3 LMI N3 error threshold window = 4
MIR % of CIR = 25 IR % Increment = 12
IR % Decrement = 25 DECnet length field = No
Default CIR = 65536 Default Burst Size = 64000
Default Excess Burst = 0
FR Config>list perm
Maximum PVCs allowable = 64
Total PVCs configured = 2
Circuit Circuit Circuit CIR Burst Excess
Name Number Type in bps Size Burst
---------------------------------- ------- ----------- ------- ------- -----
circ16 16 @ Permanent 65536 64000 0
cir22 22 @ Permanent 65536 64000 0
* = circuit is required
# = circuit is required and belongs to a required PVC group
@ = circuit is data compression capable
|
Table 20. Data Compression Configuration Commands
| Command | Action |
|---|---|
| add permanent-virtual-circuit # | Use to enable data compression on a specific PVC defined on an interface. |
| change permanent-virtual-circuit # | Use to change whether a specific PVC will compress data. |
| disable compression | Disables data compression. |
| enable compression | Enables data compression. |
| list lmi | Displays the current configuration of the interface. |
| list permanent | Lists summary information about circuits. |
| Note: | Enabling compression on orphan circuits will decrease the number of available compression sessions available for the native PVCs on the device. |
If you enable compression on a Frame Relay interface that already has compression enabled, the software asks you if you want to change compression parameters on the interface, as shown in the following example. You can change compression on the interface without disabling compression.
Example of changing compression on Frame Relay interfaces:
Config> net 2 Frame Relay user configuration FR Config> enable compression Data compression already enabled. Do you wish to continue and change an interface parameter [Y] Maximum number of run-time compression PVCs (zero means no limit) [0]? 32 Do you want orphan circuits to perform compression [Y]? The number of currently defined circuits is 5 Change all of these circuits to perform compression?
You monitor compression as you would other Frame Relay components.
"Frame Relay Monitoring Commands"
in Software User's Guide describes how to access the Frame Relay console environment and details
about the commands. Table 21 lists the compression-related commands. "Example: Monitoring Compression on a Frame Relay Interface or Circuit" shows an example of listing compression on a
Frame Relay interface.
Table 21. Frame Relay Data Compression Monitoring Commands
| Command | Display |
|---|---|
| list lmi | Lists the current status of the interface. |
| list permanent | Lists summary information about circuits. |
| list circuit | Lists the current status of a circuit. |
+ network 2
FR 2 > list lmi
Management Status:
------------------
LMI enabled = No LMI DLCI = 0
LMI type = ANSI LMI Orphans OK = Yes
CLLM enabled = No
Protocol broadcast = Yes Congestion monitoring = Yes
Emulate multicast = Yes CIR monitoring = No
Notify FECN source = No Throttle transmit on FECN = No
PVCs P1 allowed = 64 Interface down if no PVCs = No
Line speed (bps) = 64000 Maximum frame size = 2048
Timer T1 seconds = 10 Counter N1 increments = 6
LMI N2 threshold = 3 LMI N3 threshold window = 4
MIR % of CIR = 25 IR % Increment = 12
IR % Decrement = 25 DECnet length field = No
Default CIR = 65536 Default Burst Size = 64000
Default Excess Burst = 0
Current receive sequence = 0
Current transmit sequence = 0
Total status enquiries = 0 Total status responses = 0
Total sequence requests = 0 Total responses = 0
Data compression enabled = Yes Orphan Compression = No
Compression PVC limit = None Active compression PVCs = 1
PVC Status:
-----------
Total allowed = 64 Total configured = 1
Total active = 1 Total congested = 0
Total left net = 0 Total join net = 0
FR 2 > list permanent
Circuit Orphan Type/ Frames Frames
Number Circuit Name Circuit State Transmitted Received
------- -------------------------------- ------- ----- ----------- --------
16 circ16 No @ P/A 58364 58355
22 circ22 No & P/A 58364 58355
A - Active I - Inactive R - Removed P - Permanent C - Congested
* - Required # - Required and belongs to a PVC group
@ - Data compression capable but not operational
& - Data compression capable and operational
FR 2 > list circuit 22
Circuit name = circ22
Circuit state = Active Circuit is orphan = No
Frames transmitted = 58391 Bytes transmitted = 2676894
Frames received = 58383 Bytes received = 2671009
Total FECNs = 0 Total BECNs = 0
Times congested = 0 Times Inactive = 0
CIR in bits/second = 65536 Potential Info Rate = 64000
Committed Burst (Bc) = 64000 Excess Burst (Be) = 0
Minimum Info Rate = 16000 Maximum Info Rate = 64000
Required = No PVC group name = Unassigned
Compression capable = Yes Operational = Yes
R-R's received = 0 R-R's transmitted = 0
R-A's received = 0 R-A's transmitted = 0
R-R mode discards = 0 Enlarged frames = 0
Decompress discards = 0 Compression errors = 0
Rcv error discards = 0
Compression ratio = 1.00 to 1 Decompression ratio = 1.00 to 1
Current number of xmit frames queued = 0
Xmit frames dropped due to queue overflow = 0